Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3753427641_3645053052" --B_3753427641_3645053052 Content-type: multipart/alternative; boundary="B_3753427641_2086636222" --B_3753427641_2086636222 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thanks, Mike. =20 We have looked at a softcore based design with a SHAKE coprocessor (without= the NTT acceleration). Our findings support your comments below. The benefit of TurboSHAKE would be very small for HW (12 cycles per keccak-= permute round), where our current unoptimized coprocessor interface spends = more than 100 cycles transferring data With HW acceleration of SHA3 (SHAKE or TurboSHAKE) the critical path become= s NTT =20 The actual changes to the code to go to 12 rounds seem rather minor (grante= d we are not working on a production-quality implementation). =20 The software-only version, of course, is a different story. =20 -david =20 =20 From: on behalf of Mike Hamburg Date: Friday, December 9, 2022 at 9:54 AM To: Peter Schwabe Cc: "Markku-Juhani O. Saarinen" , pqc-forum , John Mattsson , "Blumenthal,= Uri - 0553 - MITLL" Subject: Re: [pqc-forum] Kyber decisions, part 1: Symmetric crypto =20 =20 On Dec 9, 2022, at 1:14 PM, Peter Schwabe wrote: =20 Mike Hamburg wrote: Hi all, Hi Mike, hi all, I mostly agree with Markku here. I think it=E2=80=99s better to domain separate based on input encoding inst= ead of based on cSHAKE. It=E2=80=99s not as broadly supported as SHAKE, and if you have several separate instances then you either need an extra permutation call or else several precomputed 200-byte states, which is significant in hardware or perhaps in embedded software. For ThreeBears I used cSHAKE(parameters || purpose || data) with a fixed personalization string =E2=80=9CThreeBears=E2=80=9D, but raw SHAKE would ha= ve been about as good =E2=80=94 using cSHAKE and personalization was probably overkill. Here the `parameters` are different between different KEM instances (in your case eg Kyber512 vs Kyber768 vs Kyber1024). The goal is that if someone accidentally reuses a seed string for different key sizes, they won=E2=80=99t get closely related keys. The `purpose` is what you=E2=80=99re using it for (hash, keygen, generate A, encrypt, PRF etc). The whole (parameters || purpose) block has a fixed 8-byte aligned size, in case clients are optimized for that. You could also put the counter in the purpose block, but I put it at the end to simplify use of parallel hashing APIs. I agree that it would be cryptographically fine to generate A using TurboSHAKE, and whether to do this is mostly a matter of support (in hardware, ISEs, parallel or serial libraries etc) vs speed. The counterpoint is that Kyber is basically fast enough already, and that introducing a different function causes more disruption than it=E2=80=99s worth even pre-standardization. I would not want to go beyond the existing mode (sponge construction in counter mode) to avoid causing problems for hardware. In particular I would not want to use a Farfalle construction. But since expanding A is called on fixed-size objects, it=E2=80=99s possible that it would not go beyond sponge mode even= if TurboSHAKE can do this in general. To help weigh this, do you have a profile for what fraction of Kyber=E2=80= =99s (or Dilithium=E2=80=99s) runtime is specifically the generation of A? That's highly platform dependent. I just ran some benchmarks on a Haswell machine for the AVX2-optimized implementation. What I'm getting is: =3D=3D=3D=3D=3D=3D KYBER 512 =3D=3D=3D=3D=3D=3D keygen: 25120 encaps: 39180 decaps: 30868 gen_A: 7472 xof: 6088 =3D=3D=3D=3D=3D=3D KYBER 768 =3D=3D=3D=3D=3D=3D keygen: 43596 encaps: 59464 decaps: 47684 gen_A: 20320 xof: 16865 =3D=3D=3D=3D=3D=3D KYBER 1024 =3D=3D=3D=3D=3D=3D keygen: 60396 encaps: 83576 decaps: 67656 gen_A: 29664 xof: 24109 Here, "gen_A" is the full cycles for generation of the matrix A, including the cycles for rejection sampling; "xof" is the cycles used on SHAKE-128, i.e., the cycles that would pretty exactly halve when moving to TurboSHAKE. Note that in this implementation, the generation of A is using a fast vectorized implementation of Keccak (vectorizing across different matrix entries), while many other calls to Keccak are sequential and thus much slower. On embedded platforms like the M4 I would expect the relative cost for "xof" to be considerably higher, simply because there is no speedup from vectorization. I can run those benchmarks when I'm back from my travels. On the other hand, in a masked implementation I would expect the relative cost of "xof" to be much lower, simply because we don't require masking in the generation of A, but we do for most other Keccak calls. With HW acceleration of Keccak it's somewhat hard to predict and it will depend a lot on how large the acceleration is: on the one hand, all Keccak calls will likely have the same cost (so matrix generation will be relatively more costly compared to other Keccak calls than in the AVX2 implementation), but on the other hand, one would expect polynomial arithmetic to use a more significant portion of the cycles, so overall the cost for Keccak permutations might not matter all that much. Does this help? All the best, Peter =20 Hi Peter, thanks for this data. It looks like the savings in the cases above, for a full key exchange assum= ing that decaps regenerates A, are about 10%, 17% and 17% for the three securit= y levels. That=E2=80=99s not nothing, but it=E2=80=99s not a huge amount eit= her. Also, in terms of absolute time savings on eg 3 GHz Haswell, even for Kyber 1024 we=E2=80=99r= e looking at about 12=C2=B5s savings for the entire key exchange. I=E2=80=99m not co= nvinced that=E2=80=99s worth the change, even though it=E2=80=99s cryptographically fine. =20 Maybe on the M4 it will be relevant, though again I=E2=80=99m not sure many= M4-class devices will be doing key exchanges that a human or time-relevant process w= ill wait for. I agree that in hardware, switching to TurboSHAKE won=E2=80=99t typically s= ave as much because, at least if Keccak is implemented in the most common one-cycle-per= - round configuration, it won=E2=80=99t be the bottleneck unless the NTT unit= is very large. In fact, the savings might be almost zero if the XOF and NTT operate in par= allel. =20 TurboSHAKE will also be annoying for hardware designers, because (speaking as a hardware designer) we will need to alter our accelerators to support i= t but as far as I can tell it isn=E2=80=99t spec=E2=80=99d yet. Since hardware h= as a long development cycle, this will mean adding a bunch of extra knobs to the Keccak accelerat= or and hoping we picked the right ones. =20 Overall, I=E2=80=99m not in favor of this change but I don=E2=80=99t think = it will be a disaster either. There will be less risk for hardware projects if you can specify what Turbo= SHAKE will look like, possibly even before deciding whether to use it. =20 Regards, =E2=80=94 Mike --=20 You received this message because you are subscribed to the Google Groups "= pqc-forum" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+unsubscribe@list.nist.gov. To view this discussion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/D58209AC-08F2-4854-813D-06FB0875C2F4%40shiftleft.= org. --=20 You received this message because you are subscribed to the Google Groups "= pqc-forum" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+unsubscribe@list.nist.gov. To view this discussion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/BB6D6DC9-33D8-43C7-905E-F4C1034B9869%40ll.mit.edu= . --B_3753427641_2086636222 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Tha= nks, Mike.

 

We have looked at a softcore based design with a SHAKE coproce= ssor (without the NTT acceleration). Our findings support your comments bel= ow.

  • The benefit = of TurboSHAKE would be very small for HW (12 cycles per keccak-permute roun= d), where our current unoptimized coprocessor interface spends more than 10= 0 cycles transferring data
  • With HW acceleration of SHA3 = (SHAKE or TurboSHAKE) the critical path becomes NTT

 

The actual chan= ges to the code to go to 12 rounds seem rather minor (granted we are not wo= rking on a production-quality implementation).

 

The software-only version,= of course, is a different story.

&= nbsp;

-david

 

 

=

From: = <pqc-forum@list.= nist.gov> on behalf of Mike Hamburg <mike@shiftleft.org>
Dat= e: Friday, December 9, 2022 at 9:54 AM
To: Peter Schwabe <= peter@cryptojedi.org>
Cc: "Markku-Juhani O. Saarinen"= ; <mjos.crypto@gmail.com>, pqc-forum <pqc-forum@list.nist.gov>,= John Mattsson <john.mattsson@ericsson.com>, "Blumenthal, Uri - = 0553 - MITLL" <uri@ll.mit.edu>
Subject: Re: [pqc-forum= ] Kyber decisions, part 1: Symmetric crypto

 

=  

On Dec 9, 2022, at 1:14 PM, Peter Schwabe &l= t;peter@cryptojedi.org> wrote:

=  

Mike Hamburg <mike@shi= ftleft.org= > wrote:

Hi all,


Hi Mike, hi all,


=

I mostly agree w= ith Markku here.

I think it=E2=80=99s better to domain separate base= d on input encoding instead
of based on cSHAKE.  It=E2=80=99s not a= s broadly supported as SHAKE, and if
you have several separate instances= then you either need an extra
permutation call or else several precompu= ted 200-byte states, which is
significant in hardware or perhaps in embe= dded software.  For
ThreeBears I used cSHAKE(parameters || purpose = || data) with a fixed
personalization string =E2=80=9CThreeBears=E2=80= =9D, but raw SHAKE would have been
about as good =E2=80=94 using cSHAKE = and personalization was probably
overkill.  Here the `parameters` a= re different between different KEM
instances (in your case eg Kyber512 v= s Kyber768 vs Kyber1024).  The
goal is that if someone accidentally= reuses a seed string for
different key sizes, they won=E2=80=99t get cl= osely related keys.  The
`purpose` is what you=E2=80=99re using it = for (hash, keygen, generate A,
encrypt, PRF etc).  The whole (param= eters || purpose) block has a
fixed 8-byte aligned size, in case clients= are optimized for that.
You could also put the counter in the purpose b= lock, but I put it at
the end to simplify use of parallel hashing APIs.<= br>
I agree that it would be cryptographically fine to generate A using<= br>TurboSHAKE, and whether to do this is mostly a matter of support (in
= hardware, ISEs, parallel or serial libraries etc) vs speed.  The
co= unterpoint is that Kyber is basically fast enough already, and that
intr= oducing a different function causes more disruption than it=E2=80=99s
wo= rth even pre-standardization.  I would not want to go beyond the
ex= isting mode (sponge construction in counter mode) to avoid causing
probl= ems for hardware.  In particular I would not want to use a
Farfalle= construction.  But since expanding A is called on fixed-size
objec= ts, it=E2=80=99s possible that it would not go beyond sponge mode even ifTurboSHAKE can do this in general.

To help weigh this, do you have= a profile for what fraction of Kyber=E2=80=99s
(or Dilithium=E2=80=99s)= runtime is specifically the generation of A?


That's highly platform dependent. I just ran some benchmarks on a<= br>Haswell machine for the AVX2-optimized implementation. What I'm getting<= br>is:

=3D=3D=3D=3D=3D=3D KYBER 512 =3D=3D=3D=3D=3D=3D

keygen= : 25120
encaps: 39180
decaps: 30868
gen_A:   7472
xof= :     6088


=3D=3D=3D=3D=3D=3D KYBER 768 =3D= =3D=3D=3D=3D=3D

keygen: 43596
encaps: 59464
decaps: 47684
g= en_A:  20320
xof:    16865


=3D=3D=3D=3D= =3D=3D KYBER 1024 =3D=3D=3D=3D=3D=3D

keygen: 60396
encaps: 83576<= br>decaps: 67656
gen_A:  29664
xof:    24109
<= br>
Here, "gen_A" is the full cycles for generation of the mat= rix A,
including the cycles for rejection sampling; "xof" is t= he cycles used on
SHAKE-128, i.e., the cycles that would pretty exactly = halve when moving
to TurboSHAKE.

Note that in this implementation= , the generation of A is using a fast
vectorized implementation of Kecca= k (vectorizing across different matrix
entries), while many other calls = to Keccak are sequential and thus much
slower. On embedded platforms lik= e the M4 I would expect the relative
cost for "xof" to be cons= iderably higher, simply because there is no
speedup from vectorization. = I can run those benchmarks when I'm back
from my travels.

On the = other hand, in a masked implementation I would expect the
relative cost = of "xof" to be much lower, simply because we don't require
mas= king in the generation of A, but we do for most other Keccak calls.

= With HW acceleration of Keccak it's somewhat hard to predict and it willdepend a lot on how large the acceleration is: on the one hand, all
Kec= cak calls will likely have the same cost (so matrix generation will
be r= elatively more costly compared to other Keccak calls than in the
AVX2 im= plementation), but on the other hand, one would expect polynomial
arithm= etic to use a more significant portion of the cycles, so overall
the cos= t for Keccak permutations might not matter all that much.

Does this = help?

All the best,

Peter

 

Hi Peter, thanks for this data.=


<= br>

It looks like the savings in the cases above, for a full key exch= ange assuming

that decaps regenerates A, are about 10%, 17% and = 17% for the three security

levels.  That=E2=80=99s not nothing, = but it=E2=80=99s not a huge amount either.  Also, in terms of

ab= solute time savings on eg 3 GHz Haswell, even for Kyber 1024 we=E2=80=99re = looking

at about 12=C2=B5s savings for the entire key exchange. =  I=E2=80=99m not convinced that=E2=80=99s worth

<= /div>

the change, even= though it=E2=80=99s cryptographically fine.

 

Maybe on the M4 it will be relevant, though ag= ain I=E2=80=99m not sure many M4-class

devices will be doing key exch= anges that a human or time-relevant process will

=

wait for.



I agree that in hardware, switching to TurboSHAKE won=E2= =80=99t typically save as much

because, at least if Keccak is impleme= nted in the most common one-cycle-per-

round configuration, it won=E2= =80=99t be the bottleneck unless the NTT unit is very large.

In = fact, the savings might be almost zero if the XOF and NTT operate= in parallel.

 

TurboSHAKE will also be annoying for hardware designers, because (speaki= ng

as a hardware designer) we will need to alter our accelerator= s to support it but

as far as I can tell it isn=E2=80=99t spec= =E2=80=99d yet.  Since hardware has a long development

cycl= e, this will mean adding a bunch of extra knobs to the Keccak accelera= tor

and hoping we picked the right ones.

<= div>

 

Overall, I=E2=80=99m not in favor of this ch= ange but I don=E2=80=99t think it will be a disaster either.

There wi= ll be less risk for hardware projects if you can specify what TurboSHAKE

will look like, possibly even before deciding whether to use it.=

 

<= div>

Regards,

=E2=80= =94 Mike

--
You re= ceived this message because you are subscribed to the Google Groups "p= qc-forum" group.
To unsubscribe from this group and stop receiving = emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
To view this discu= ssion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/D58209AC-08F2-4854-813D-06FB0875C2F4%40shiftleft.= org.

--
You received this message because you are subscribed to the Google Groups &= quot;pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+un= subscribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.c= om/a/list.nist.gov/d/msgid/pqc-forum/BB6D6DC9-33D8-43C7-905E-F4C1034B9869%4= 0ll.mit.edu.
--B_3753427641_2086636222-- --B_3753427641_3645053052 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUiwYJKoZIhvcNAQcCoIIUfDCCFHgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJRMIIE+jCCA+KgAwIBAgITWQAE2Vny3pXMUUj0WAAAAATZWTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMDYxNjE3MjEzMloXDTI1MDYx NTE3MjEzMlowYDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEfMB0GA1UEAxMWU3RvdHQuRGF2aWQuVC41MDAxNzAyNzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMO+HxiCyu1y/QxKTRHvsNbyiGvsIsYn cJ6bOwjL7k5eJ27f8Y9a2+fe6G64phLONv1oBV6HSvUbXxCL+1C1NvTWUWr91597NiWKsSWX gaS/LPvlZ5ThSX8ozo/Wp/cNp31wWKiIDRX1IMQ2IrYCmOBteZJqZO2zvrO4HrRKbK4EnbGz KxNUFfa66djmxUiBdeSr3+dAAHkD0fF4tfUa5hBCQC0iWDxhhzfo0G/8MJ3uyKIlVx8sv7f+ yt+qAi6ghVQY7WcCXpC6zVustgkjOexUpCHXQB1/cxV6WLEBpCotF+i7xQLtlImc/+FfwFvc aSeZClTzwlt9h9WBBCGFl30CAwEAAaOCAbowggG2MB0GA1UdDgQWBBRofBWj7zFgLXwDW5fE TvbthkC7NDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEKMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCEGA1UdEQQaMBiB FkRhdmlkLlN0b3R0QGxsLm1pdC5lZHUwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAnBgkr BgEEAYI3FAIEGh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IB AQBzW6KkAZrTON7xdP1ums7pHRJPYGn8sgsLRPdBWcdJHjAN3RsQEx8hBBcrDuNlSsqj2VGx nrvlK0Fj3F+QxGnkUKNGTfW8q0DdE2DU2Z0zcl5EpMEuYIrXDuqkfvqRjlNr3Yloyp7heJX5 +tVinVIJt4B8vBrgkhZEWkLrQofy+5MkAVXKaCm3nyGMNesRGSEyvxH0op6plQdUYZcMYoqM BRdDahG955PauFnzr1WVBHghs0A7c1T8iBX5lVa4d+p4E6iCRuZPUe/gAlTPJF8cIm9TDtwl lVeeffFDZHn6OfzXnEFZwkBATrxtzlTUTymGi1bI1lKkJiw6sp6HBPnvMIIEwDCCA6igAwIB AgIBBjANBgkqhkiG9w0BAQsFADBWMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9NSVRMTCBSb290IENBLTIw HhcNMTcwMzAyMTIwMDAwWhcNMjYwMzAyMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UE CgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRM TCBDQS01MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp5qDDr05H8O56tfZq1ms xmmvkPN1L9PgE1096upK/lhMSDCGfOwu+FgnEV6bzu7r8ex7zLGFgBR1vd8EMIY8rcRyDmYC jSeFZxlQ1JfiiO4NJ/fmY7d4Qdx4R23L23vfmOI8/l8woi5djmmLyAim8b2wUgi7TxHmUOse k2+hCtMptIL2Hhzt5LrmPkiRyTJbW6y5yFS8Y2azVUu+81yr7ukN4UnZESAe5CYBF3y/qf8/ 9qfeGxBGdk50M9E5Doxviau1JV5RUbb7GHAzxEA91DZGbFnF4AtYVxvExpJ1HAIZRsVYZSpR S5jXe9+NrHhstrPWMTQ50hPnl07W9COSywIDAQABo4IBnDCCAZgwEgYDVR0TAQH/BAgwBgEB /wIBADAdBgNVHQ4EFgQUL++7xg0du+lq/qxn8wc7CHb2S1kwHwYDVR0jBBgwFoAU/8nJZUxT gPGpDDwhroIqx+74MvswDgYDVR0PAQH/BAQDAgGGMGcGCCsGAQUFBwEBBFswWTAuBggrBgEF BQcwAoYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMUkNBMjAnBggrBgEFBQcwAYYb aHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExSQ0EyMIGSBgNVHSAEgYowgYcwDQYLKoZIhvcSAgED AQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYLKoZI hvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQELBQADggEBADCWEcCzyfdSu3tpgNjY9dFtKOST B2JGmvnLS/P8WPEMyBxSOSI/osnaTzfSgmJ/+EsvNE92jaGJBZUtBkUF4X9J7ImO01icACsO AIjv8id+/6ESkYLckYnL2iekY5RwlwTmpRS8PVLaaHT+P4nQudZcc7KJWkGa2gY1Xuzy/eT4 Uuw/ttjX3yJ8y3SG9QwX+eDcDlXzyIAAbcR9X4Wa42uxIUfUaFMORNTuolmgLj/8VoUk0BVp YcgNP5JCIvfx12mNIWJ4XI3Gzz6o6cnyIUhY414Y6iu7dsD60qwRSxVG5y4jZYEB67zWBeSK oCH50gViK5t63y4aWWSf8Se2H+gwggOKMIICcqADAgECAgEBMA0GCSqGSIb3DQEBCwUAMFYx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQL EwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNjA0MjAxMjAwMDBaFw0zNTA0 MTkyMzU5NTlaMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0 b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL91qARBjjibZuLnL2n+ryiBT7PMGrQnekpsKv13kTaO z94zyMTT8Bd/fERg1JjySFwO4ncw+o9KKRSFvpC6mMnvXu/PD1dHamiZV/PNfHzQ20hPvAeo Ynqik0e1XziO+FFUBFClURbkRcOrlWLr4HsNk4/wtnRHnt+3q7kJeZx5G1djrFp2ezvsrfnr Xeh0XGly5T/avFioANwe75DlSDAiqALmlo/gRauyvljZIsovynTh/SZjqW8kSuI3AO8Wy5xf CRVEjYOXOGNQSaxWmbZAnhujZvaeduBpZZERcz4KY/FYnFfgCvva2NO3U8dNpGKLU5yrstGM QQMLFF8QEBMCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU/8nJZUxTgPGp DDwhroIqx+74MvswHwYDVR0jBBgwFoAU/8nJZUxTgPGpDDwhroIqx+74MvswDgYDVR0PAQH/ BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IBAQB6mHxH/9yeWjCoZWEND51AGzAfI2Uq/fx743zh dNHKxVAn0q6hvCUMKPkv4quuoHKethRICdH0JA4FYOpvgthE6NS6FoksYWAn3EiEBApY5V8E fMBUmshfNtkuvSKrx4XauHefI1OoGIurLI1OL8LL7FS0SSpP5vwoP8PIFumBzOWoQQ+v+QnH pdnyO6EprJDvfdfqLawtdWHw8Ahb8+wJtK/ivYlYUlrWuIZiLldGAYmtO3mSkjtNiz4EPGDs 95LtGLfpofFVkSrsdgnGIzKZPlg1dATKe+bam+qagRZHCrxAV6sYPvPhv7po4ouB9HOZLyYW kMspG5jipsTvSHCSMIIE/TCCA+WgAwIBAgITWQAEPY/351gNXCQf6AAAAAQ9jzANBgkqhkiG 9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDcyOTE0MjAzOVoX DTI0MDcyNzE0MjAzOVowYDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEfMB0GA1UEAxMWU3RvdHQuRGF2aWQuVC41MDAx NzAyNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALe9KXFoKyhBJeRNo6MsXwo1 sYCmwEr3wiQINXUgfz+VU99yw9c4/sbojfuJcRjVPg79crGw+84rtEAHL5b33nwyFWrXhkJ0 OggdP1EhBQdfgIFfuTWTJtgYd3OPDLqGlKVJ8bAmSpfsQxGH5eFA04UIpitHfbSPSA0RXU8c fSWOyLosrXuBElsZSUl2oqyM4iBnqyQtuEpQI9hej6yRe30BWfvgqW7Pdq74G9ZgSFCBh4dA G93F6AtsThhNeDDwNaoODgp3KMovFSfjMxlRPy+9P4NQBQk1y+ALh2Fv9zc+QsPSA7oXw8h7 2tPuKEYKaJA89m3Y9CaXYvKEw2tTUXECAwEAAaOCAb0wggG5MB0GA1UdDgQWBBTR5nPGw6g6 lBY6eR2Aedhr65XmkTAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn 8wc7CHb2S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bC9sbGNhNTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9v Y3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr 0HCD6+0gAgFkAgELMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMCEG A1UdEQQaMBiBFkRhdmlkLlN0b3R0QGxsLm1pdC5lZHUwGAYDVR0gBBEwDzANBgsqhkiG9xIC AQMBCDAnBgkrBgEEAYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3 DQEBCwUAA4IBAQAsbfXCb+N33XoE/cANcfjLH5gdycPuaOI4paPQkM/OoN7QUdBr15WeWmUE A3uW32UXuvvcrK1QYqeR0q/q/kNGy7t6mfrwKX1SmjXveU3GR5AafMMPsZNGXnp6uf0UKfLM NzLL8MR8N1caviMknXDD5ArZZ58vSjIN7sNc0tpbF2NgpfHcth7Icgb2hdiTZENzxBVCWGA4 q9+gJCOp5p2YBgcWb2Bq1vTwZTYCJcba8LKcbsaYXDfgoYJlrjlThp9fxPhUB2ea+hkqLlQD WivIZap5rB5JLGEXYarVVShnOcfW44iWZ1BzXuixet5t9CiW8qWGeOxdpV9afTeyxSW3MYIB /jCCAfoCAQEwaDBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3Jh dG9yeTEMMAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01AhNZAATZWfLelcxRSPRY AAAABNlZMA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIK9TsMAAAaKQ0YckVkFG Dn0gRpaq8wnyYa7RkVRCK6/8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTIyMTIwOTE1NDcyMVowDQYJKoZIhvcNAQEBBQAEggEAFIKxYiNnHODXVSaraIs/ qAAs0Wqi/Bsj3RfKX2jgSNtVk5oQBwHlVJwUvqAWyMIMZW7LZ/eC0olxRlgdIw58grvSoCG0 9Ao3TPqG0vHmRQDGQOEh3OnfIDRmG2qPEv4Nd0+cT7Bwnck4U6NLMJpC21ZApjS6ppUIO9s+ 5kejb+k93vCVIpo4b4iTIFSYsvsIzXMOBHlY4xCv3fphjSHsvcejkPHuOTKZMGhDWi78OQPM BkuPIjoEbAFPYVAT0Hd7ykllci6u6Bv1BSraZnI0uVCKIMPaxU2x9Sj2jfFSk2n+OZViZ4Wa YI7Bec56t3ErVFLPpZn/gbv/TozQkX+W7A== --B_3753427641_3645053052--